Business people tend to either manage processes or projects. Processes lend themselves to repeatable, systematic measures that allow the manager of the process to determine if that process is performing as usual or if something about the process has changed. At the highest level, a business itself is a “process”—taking input resources (time, capital, people, materials, etc.) and producing an output (sales and profits).
Businesses build processes to systematically execute their plans and produce a predicable outcome. This leads to a fundamental question, what is/has changed? People need to know when some input or output of a process has changed, because it threatens the predictability of an organization, and might indicate a need to alter the current processes in order to get the desired outcome.
Traditionally, managers received reports (paper or electronic) to review the key business process metrics and through visual inspection and experience tried to detect if something had changed. Unfortunately, this process of manual scanning was highly time-intensive and required significant knowledge on the part of the manager.
In recent years, manual alerting software has been introduced which allows the manager to set thresholds for key process metrics. The thresholds may be represented as constants or, more recently, as expressions. The software then monitors the metrics over time and triggers an alert when the threshold has been crossed.
Despite its advantages over earlier approaches, alerting software still requires significant user knowledge in order to set correct thresholds. Metrics often fluctuate, sometimes widely, over time. Setting a threshold too close to the historical average may result in many false alarms, i.e., an alert being triggered while in a normal state. On the other hand, setting a threshold too far from typical values may result in an alarm never being generated, despite the occurrence of a fundamental change in a process.
Furthermore, conventional software only automates the periodic inspection of data. If the user has hundreds or thousands of process metrics to monitor, the user must configure hundreds or thousands of alerts and for each must determine the correct threshold value or expression. Moreover, the user must periodically adjust the thresholds as conditions change over time. Setting and maintaining all of the alerts can be extremely tedious.
Increasingly, business processes are being represented in multidimensional databases. Conceptually, a multidimensional database uses the idea of a data cube to represent the dimensions of data available to a user. For example, “sales” could be viewed in the dimensions of product model, geography, time, or some additional dimension. In this case, “sales” is known as the measure attribute of the data cube, and the other dimensions are seen as feature attributes. Additionally, a database creator can define hierarchies and levels within a dimension (for example, state and city levels within a regional hierarchy).
Due to their complexity, multidimensional databases further exacerbate the monitoring problems discussed above. Manually creating thresholds for monitoring processes (measures) across dimensions can be extremely burdensome or practically impossible in some cases.